Subject: RE: Note from you attached below

From: Stephane St-Hilaire <[email-masked]>
Date: Wed, 18 Sep 96 11:01:00 PDT

Hi John
I aggree with your replies, and I don't have anything against   
standardizing on the location of a message type field, It just appeared   
to me that at this point there would be some "resistance" (I don't know   
where I got this idea ; ) ) against adding things to the document unless   
they were absolutely needed. And at the same time I figured as long as we   
are talking about vendor specific extensions some of these vendors might   
want to have full "creative" freedom as to how they setup the rest of   
their header.

I propose the following compromise (tell me what you think): The document   
could at least specify where the AIW as an organisation intends to store   
it's message type field for its UDP messages (your proposed location is   
fine). This way a vendor that believes that what ever feature he is   
designing is sufficiently useful and could become a standard can take   
that information into account whereas someone who doesn't believe so can   
do as he chooses.

This is the issue we better discuss.  I have been recently investigating
how to do DLSw partner discovery using UDP frames.  The most likely   
method
would be to occasionally send out a frame to all configured multicast
addresses
a short message indicating that a DLSw box is present in the network and
soliciting replies from DLSw partners to find out who else is in the   
network.

If we choose a method such as this, I would want these messages to be as
short as absolutely possible.  So ... I'd rather have the DLSw UDP OUI   
header
of length 7 or 8, than the SSP message header of 16 or 72.

I have a suggestion here, even though we can in this particular instance   
define new messages, I wonder if we could not instead re-use an existing   
SSP message and extend its's use. Just as we now can send CANUREACH_ex on   
UDP, we could extend the CAPEX messages to be sent in that manner as   
well. A DLSw router that wants to discover what other possible partners   
are out there (and their capabilities) could multicast a CAPEX request,   
and then wait for responses. It would probably make sense to limit the   
number of response frames from partners by only responding positively as   
in the CANUREACH. Anyway I haven't really spent to much time figuring all   
the details here but it just strikes me as something that may make some   
sense, what do you think ? On another note, there is also a service   
location protocol being drafted by the IETF for IP (there's an IBMer on   
that) that can be of use for that purpose too (maybe as an additionnal   
technique).

Regards

 ----------
From:   
 aiw-dlsw-scalability[SMTP:[email-masked]]
Sent:  Wednesday, September 18, 1996 9:49 AM
To:  stephanh
Subject:  Note from you attached below

Stephane, Thanks for the comments - my replies below.

Jon Houghton

>> ------------------------------- Referenced Note   
 ---------------------------
>> Received: from www.raleigh.ibm.com by vnet.IBM.COM (IBM VM SMTP V2R3)   
with
TCP;
>>    Tue, 17 Sep 96 13:32:23 EDT
>> Received: from localhost.raleigh.ibm.com by www.raleigh.ibm.com (AIX
3.2/UCB 5.64/4.03)
>>           id AA11564; Tue, 17 Sep 1996 13:32:01 -0400
>> Date: Tue, 17 Sep 1996 13:32:01 -0400
>> Message-Id: <[email-masked]>
>> Errors-To: [email-masked]
>> Reply-To: [email-masked]
>> Originator: [email-masked]
>> Sender: [email-masked]
>> Precedence: bulk
>> From: Stephane St-Hilaire <[email-masked]>
>> To: [email-masked]
>> Subject: RE: DLSw OUI Header
>> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios   
Kotsikonas
>> X-Comment:  DLSw scalability issues
>>
>>
>> Hi just a few more thoughts,
>> Even though this message type idea is not a bad one, I don't think it   
is
>> indispensible per say.
>> Obviously a given organisation will need to standardize where it will   
put
>> a message type style field passed the standardized header (but that   
can
>> be diffrent for each organization really).
>> So when the AIW starts defining some messages it will have to be
>> consistent has to where such a field will be localized to faciliate
>> parsing of frames with that OUI value.

I agree, the AIW will have to standardize where a message type field is
located.
At the last AIW, using an OUI=0x000000 as a method of representing
AIW blessed UDP messages was discussed.  It was brought up that company A
could implement a proprietary UDP message and then propose it to the AIW
to become standard.  If it succeeded, all that may need to change is the
OUI (from the company's OUI to the OUI of 0s).

All I was proposing is that we spend a few moments now standardizing what
part of the message following the OUI we need to to make this conversion
easiest for companies.

>> The evening to 8 bytes is not a bad thing though but since vendors   
will
>> probably be adding fields to this startup standard header anyways this
>> becomes a somewhat lesser issue.

I agree - this was only mentioned as a side benefit, not a reason for
implementing it.

>>
>> I still think that if a given feature (that could have started up as a
>> vendor specific thing) becomes sufficiently interesting for the AIW to
>> want to endorse it, that it should favor assigning "real" SSP message
>> types (with the normal SSP header) instead of using this "vendor
>> specific" provision.

This is the issue we better discuss.  I have been recently investigating
how to do DLSw partner discovery using UDP frames.  The most likely   
method
would be to occasionally send out a frame to all configured multicast
addresses
a short message indicating that a DLSw box is present in the network and
soliciting replies from DLSw partners to find out who else is in the   
network.

If we choose a method such as this, I would want these messages to be as
short as absolutely possible.  So ... I'd rather have the DLSw UDP OUI   
header
of length 7 or 8, than the SSP message header of 16 or 72.

---

From: Stephane St-Hilaire <[email-masked]>
Date: Wed, 18 Sep 96 11:50:00 PDT

Hi again Jon (sorry about misspelling your name on my previous mail.)

At the AIW, it was determined by the group that the most feasible way
to solve this problem would be use a different read port.

Right, I was actually thinking that we would already be using a different   
read port as it had been mentionned at the AIW and therefore that all of   
this would be doable but it's true that the document doesn't mention this   
new read port. You're absolutely right that if we don't use a new read   
port for this enhancement it is not feasible (without becoming   
incompatible with most existing implementations).

Most, if not all, RFC 1795 implementations wait until both TCP
connections are active before sending Capex.
It's too bad that the TCP connection establishment issues have been left   
out of the two RFCs, that has caused a lot of headaches to the   
implementors.
Some 1434 implementations will not even respond to a CANUREACH if it was   
sent by a partner before they had established their local (write)   
connection to the initiator. I'd call this a buggy implementation but   
since the RFC doesn't talk about this in great details the implementor   
will not likely modify is behavior, so this waiting for both TCP   
connections to be up problem is (at least in my personnal experience) a   
result of having to interoperate with implementations that don't support   
all possible use cases of TCP connection establishment (which they should   
since no details are provided by the RFCs). Anyway that just a general   
comment, I feel better now.

RFC 1795 says header length is 72 or 16 and the message length is the
number of bytes following the header.
So, based upon this I would assume the header length is 7 (or 8 if we add
message type) and the message length is length of everything beyond.
Is this your assumption?

Not really, my assumption is that the header lenght is at least 7, since   
the document standardizes the first 7 bytes of the header. Beyond that   
any vendor can add fields to the header and that is why I mentionned 7   
(or 8 depending on the outcome of your proposition) up to 255 as possible   
values.

The only important point I have here is that the message length was added
to the DLSw UDP OUI header to cover the case in which one of these   
messages
ends up in the TCP stream.  If this happens, we'd better know what the   
total
length of the stream is - not assume we all know.

I'm not proposing we define in great detail what all the fields in the   
DLSw
UDP OUI header are, but if it doesn't matter what is in these fields,   
then I
propose we get rid of them and save bytes in the header.  If it does   
matter,
then lets define them properly and avoid confusion.

I think there's probably a need for clarification in the document   
afterall, a few lines on the meaning and possible values of each field   
can clarify all of this for everyone indeed.

The problem is that I can not implement anything at this point based upon
this statement.  Until I know what messages are of this format and what   
the
format is - I can't do anything.  So I ask the opposite - what do we gain
by leaving it?  I read it and assume that there is something I should
implement based upon it - and there's not.

The only thing we gain by leaving it, is that as new documents are   
prepared, to present new UDP frames that will have subvectors at some   
point in time, the author of that (or these) document will not have to   
mention this general "philosophy" again. He can simply refer to this   
document which is not a bad thing considering it is the first document to   
present UDP used in DLSw.
You're right that right now you don't have to implement anything and the   
gain I'm talking about is not a huge one but still I think the paragraph   
does serve a pupose be it a small one. I'd personnaly would rather see it   
stay, but I don't feel very strongly about this issue, I wonder how Dave   
feels about this ?

Cheers
Stephane St-Hilaire

 ----------
From:   
 aiw-dlsw-scalability[SMTP:[email-masked]]
Sent:  Wednesday, September 18, 1996 10:48 AM
To:  stephanh
Subject:  Note from you attached below

Stephane,  Thanks also for these comments.  Replies below.

Jon Houghton

with
TCP;
>>    Tue, 17 Sep 96 13:44:40 EDT
3.2/UCB 5.64/4.03)
>>           id AA21935; Tue, 17 Sep 1996 13:44:17 -0400
>> Date: Tue, 17 Sep 1996 13:44:17 -0400
>> Message-Id: <[email-masked]>
>> Subject: RE: DLSw scalability proposal comments
Kotsikonas
>> >>   At the last AIW, we discussed that many DLSw implementations
>> >>   bring up both TCP connections before doing capabilities exchange.
>> >>   This being true, the optional enhancement discussed in this
>> >>   paragraph is not feasible.
>> I don't understand how this enhancement is not feasible ?

RFC 1434 implementations do not sent Capex at all.

Most, if not all, RFC 1795 implementations wait until both TCP
connections are active before sending Capex.

So, if we choose to try to implement an enhancement in which
we only bring up one TCP connection and wait for the Capex from
the partner to determine whether to bring up the second TCP
connection, it will not be compatible with most current 1434 and
1795 implementations.

If you receive an TCP open indication and immediately send out a
Capex without bringing up the other TCP connection, the following
will happen:

If the partner is a 1434 box, it does not process the Capex;
 your box receives nothing.

If the partner is a current 1795 box, it does not send a Capex until
 your box has opened the second TCP connection; your box receives   
nothing.

If the partner is a new 1795 v1.1 box, it could send a Capex immediately
 upon receiving the Capex.

So, you would either receive nothing or a Capex indicating you can   
support
 multicast.  The problem is .... how long do you wait before you know you
 have received nothing and must bring up the second TCP connection.
 For NetBIOS, we don't have time to wait.

At the AIW, it was determined by the group that the most feasible way
to solve this problem would be use a different read port.

>>
>> >> 3) "UDP SSP Packet Handling" section
>> >>    I think the statement referring to skipping portions of a UDP
>> >>    SSP message should be removed.
>> Well that section was probably put there to prepare for future message
>> types so the only question is: What would we gain by removing it ?

The problem is that I can not implement anything at this point based upon
this statement.  Until I know what messages are of this format and what   
the
format is - I can't do anything.  So I ask the opposite - what do we gain
by leaving it?  I read it and assume that there is something I should
implement based upon it - and there's not.

>>
>> >>    The only question that I have is - do we want to define exactly
>> what
>> >>    header length and message length fields are?  More specifically,   
is
>> >>    header length the length up to the end of the OUI or can it be
>> longer?
>> The document mentions that it can be other than 72, so the header   
lenght
>> can probably be anything from 7 to 255.

My assumption too - can we state it.  Actually, I assume it is 7.

>>
>>
>> >>       I am assuming that header length and message length can be
>> anything that
>> >>       we want given that header length + message length = total   
data
>> length,
>> >>       and the header length is at least 7 bytes (includes defined
>> info).
>> That's how I see it too. I'm not sure that we need to explain the   
meaning
>> of these lenghts fields further since RFC 1795 uses the same   
terminology
>> (header lenght and message length) with sufficient information we   
(may)
>> need to add one more reference to RFC1795 in this section...

RFC 1795 says header length is 72 or 16 and the message length is the
number of bytes following the header.
So, based upon this I would assume the header length is 7 (or 8 if we add
message type) and the message length is length of everything beyond.
Is this your assumption?

The only important point I have here is that the message length was added
to the DLSw UDP OUI header to cover the case in which one of these   
messages
ends up in the TCP stream.  If this happens, we'd better know what the   
total
length of the stream is - not assume we all know.

I'm not proposing we define in great detail what all the fields in the   
DLSw
UDP OUI header are, but if it doesn't matter what is in these fields,   
then I
propose we get rid of them and save bytes in the header.  If it does   
matter,
then lets define them properly and avoid confusion.

>>
>>
>> Stephane St-Hilaire (Eicon Technology)
>>

---

From: [email-masked]
Date: Wed, 18 Sep 96 13:02:11 EDT

Stephane, ....

Jon Houghton

>> ------------------------------- Referenced Note ---------------------------
>> Received: from www.raleigh.ibm.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP;
>>    Wed, 18 Sep 96 12:56:02 EDT
>> Received: from localhost.raleigh.ibm.com by www.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
>>           id AA30145; Wed, 18 Sep 1996 12:55:42 -0400
>> Date: Wed, 18 Sep 1996 12:55:42 -0400
>> Message-Id: <[email-masked]>
>> Subject: RE: Note from you attached below
>> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

Sounds OK to me.

>> that) that can be of use for that purpose too (maybe as an additionnal

You and I could probably go for many more rounds on this one.  So, if you don't
mind, I'll probably defer commenting on how we might implement discovery of
DLSw partners until I can put a proposal out.

The only point I had here is that there might be legitimate uses for standardized
UDP messages that have a format other than an SSP message - I'd personally like
to keep this ability to get around the 72 byte overhead of a full SSP header
in cases where it is really important to.

---

From: [email-masked]
Date: Wed, 18 Sep 96 13:12:18 EDT

Stephane, ....

Jon Houghton

>>    Wed, 18 Sep 96 12:56:50 EDT
>>           id AA19566; Wed, 18 Sep 1996 12:56:28 -0400
>> Date: Wed, 18 Sep 1996 12:56:28 -0400
>> Message-Id: <[email-masked]>

I'd like to not lose sight of my original comment.  I don't see how we
can come to approval on RFC 1795 v1.1 function until we do one of the
following:
  - produce a written proposal, review it, and approve it;
    update scalability document with any appropriate changes to this paragraph
  - agree that there will be no proposal;
    update scalability document to remove most of this paragraph

>> comment, I feel better now.

I agree that it wasn't well documented.

>> can clarify all of this for everyone indeed.

That's what I think is needed too.

>> stay, but I don't feel very strongly about this issue, I wonder how Dave

I lean the other way - to take it out.  But I too do not feel strongly.